In order to meet a variety of forums and new technologies related to the 4th generation mobile communications, the 3rd Generation Partnership Project (3GPP) which aims to provide technical specifications of the 3rd generation mobile communications system has proceeded with research for the Long Term Evolution/System Architecture Evolution (LTE/SAE) technologies since year-end 2004 as a part of efforts to optimize and enhance performances of the 3GPP technologies.
The SAE mainly led by the 3GPP SA WG2 relates to research of network technologies which aims to determine a network structure together with the LTE work of the 3GPP TSG RAN and to support mobility between networks of different versions. Recently, the SAE has been considered one of the essential standardization issues of the 3GPP. Such work is to develop the 3GPP to be a system based on the IP and supporting a variety of radio (wireless) connection technologies, and has progressed with the aim of an optimized packet-based system capable of minimizing a transmission delay with enhanced data transmission capability.
The SAE upper level reference model defined by the 3GPP SA WG2 may include a non-roaming case and roaming cases with a variety of scenarios. Detailed descriptions thereof are given in 3GPP TS 23.400a and TS 23.400b. FIG. 1 is a schematic reconfiguration diagram of such network structure.
FIG. 1 is view of an evolved mobile communication network.
One of the distinctive characteristics of the network structure shown in FIG. 1 is that it is based on a 2 tier model having an eNode B of the Evolved UTRAN and a gateway of the core network. The eNode B 20 has a similar function, although not exactly the same, to the eNode B and RNC of the existing UMTS system, and the gateway has a function similar to the SGSN/GGSN of the existing system.
Another distinctive characteristic is that different interfaces are exchanged by the control plane and the user plane between the access system and the core network. While an Iu interface exists between the RNC and SGSN in the existing UMTS system, two separate interfaces, i.e., S1-MME and S1-U, are used in the Evolved Packet Core (SAE) system since the Mobility Management Entity (MME) 51 which handles the processing of a control signal is structured to be separated from the gateway (GW).
For the GW, there are two types of gateways: a Serving Gateway (hereinafter, ‘S-GW’) 52 and a Packet Data Network gateway (hereinafter, ‘PDN-GW’ or ‘P-GW’) 53.
FIG. 2 shows the structure and communication process of an MTC device.
A Machine Type Communication (MTC) device may be used in a mobile communication system. The MTC refers to data communications between machines performed without human interference, and a device used for these communications is referred to as an MTC device. A service provided by the MTC device is different from a communication service performed with human interference, and may be applied to a variety of services.
The aforementioned MTC device is a communication device is a communication device that performs communication between machines, which is not much different from a UE that needs human interaction, except that it needs no human interaction. That is, the MTC device may correspond to a UE that needs no human interaction. However, from the viewpoint that no human interaction is needed, if a message transmission/reception method (e.g., paging message transmission/reception method) for a UE that needs human interaction is fully applied to the MTC device, some problems may occur.
Referring to FIG. 2, when a measuring service, a road information service, a user electronic equipment calibration service, or the like, provided by the MTC device, received by an eNB, the eNB may transmit it to an MTC server, and therefore the MTC user may use the service.
It is often the case that the MTC device performs communication alone in a place that needs no human interference since it performs communication without human interaction.
FIG. 3 is a conceptual diagram showing a 3GPP service model for supporting MTC.
Although GSM/UMTS/EPS with the 3GPP standards for supporting MTC are defined to perform communication over a PS network, the present specification describes a method applicable to a CS network as well.
In the current technical specification, the use of an existing 3GPP bearer is suggested for the definition of the network structure. A method using a short message service (SMS) for data exchange between an MTC device and an MTC server was proposed as one of alternative solutions. The use of SMS was proposed, considering that a small amount of digital data including meter reading information and product information will be an object of an MTC application in view of the characteristics of the MTC application, by which an existing SMS method and an IMS-based SMS method can be supported.
In FIG. 2, MTCsms is a data exchange interface using an existing SMS method, and MTCi is a data exchange interface for a 3GPP bearer service and IMS.
In the current 3GPP standards, three architecture models for MTC are defined as follows: a Direct Model, an Indirect Model, a Hybrid Model, and so on. The Direct Model is a model in which an MTC application is connected directly to an UE over a 3GPP network and performs communication under the control of a 3GPP network provider. The Indirect Model includes two models: a model in which an MTC application is connected to an MTC server outside a 3GPP network to perform communication with a UE under the control of an MTC service provider; and a model in which an MTC server exists within a 3GPP network and an MTC application is connected to an UE to perform communication under the control of a 3GPP network provider. The Hybrid Model involves the co-existence of the Direct Model and Indirect Model. For example, user plane is a method of communication using the Direct Model and control plane is a method of communication using the Indirect Model.
As described above, Machine Type Communication (MTC) involves communication performed between machines, which may result in overload in some cases. For example, overload may be generated due to the following reasons:                there is a malfunctioning in the MTC server or MTC application;        an external event triggers MTC devices to attach/connect; and        a large number of MTC devices are configured such that a specific program is repeatedly operated at a specific time.        
To resolve the problem of such network congestion or overload, a network node can reject a specific access. Such an access restriction is enabled according to an APN (i.e., congested APN) or MTC group. Such access restriction may cause the network node to transmit a back-off time to the MTC device and provide information about restricting access and session setup until the duration of the back-off time expires.
The network node may set the back-off time by using a randomization method. Also, the access start time is randomized to prevent simultaneous congestion at a specific point of time.
FIG. 4 shows a procedure of rejecting access from an UE in case of network congestion or overload.
As can be seen with reference to FIG. 4(a), when a UE 10 performs an attach or tracking area update (TAU) procedure through a first (e)NodeB 21 in case of network congestion or overload, a node, e.g., MME/SGSN 51, within the network rejects the attach or TAU request according to a network situation such as an operator policy.
Also, the MME/SGSN 51 may transmit a back-off time when it performs the rejection so that the UE 10 does not have to attempt access until expiry of the back-off time.
At this point, the UE 10 does not have to perform an attach or TAU procedure through a second (e)Node 22 based on the back-off time.
Alternatively, as shown in FIG. 4(b), in case of network congestion or overload, a node, e.g., MME/SGSN 51, within the network may transmit a back-off time to the UE 10 through the first (e) nodeB 21 according to a network situation such as an operator policy.
Then, the UE 10 does not have to perform an attach or TAU procedure through the second (e)Node 22 based on the back-off time.
FIG. 5 is a view showing a relation between (e)NodeB and Home (e)NodeB.
In the 3rd or 4th generation mobile communication systems, attempts continue to increase their cell capacity in order to support high-capacity and bi-directional services such as multimedia contents, streaming, and the like.
In other words, with the development of communication and widespread multimedia technologies, various high-capacity transmission technologies are required, and accordingly, a method of allocating more frequency resources is used to increase radio capacity, but there is a limit to allocate more frequency resources to a plurality of users with restricted frequency resources.
In order to increase cell capacity, there has been an approach in which high frequency bandwidth is used and the cell diameter is reduced. If a cell having a small cell radius such as a pico cell is applied, it is possible to use a higher bandwidth than the frequency that has been used in the existing cellular system, thereby providing an advantage capable of transmitting more information. However, more base stations should be installed in the same area, thereby having a disadvantage of high investment cost.
In recent years, a femto base station such as Home (e)NodeB 30 has been proposed among the approaches for increasing cell capacity using such a small cell.
Studies on the Home (e)NodeB 30 have been started by 3GPP Home (e)NodeB WG3, and also in recent years, actively proceeded by 3GPPSA WG2.
The (e)NodeB 20 illustrated in FIG. 5 corresponds to a macro base station, and the Home (e)NodeB 30 illustrated FIG. 5 may be a femto base station. This specification will be described based on the terms of 3GPP, and the term (e)NodeB is used when referring to both NodeB and eNodeB. Also, the term Home (e)NodeB is used when referring to both Home NodeB and Home eNodeB.
The interface illustrated in a dotted line denotes the transmission of control signals between the (e)NodeB 20 or Home (e)NodeB 30 and the MME 510. Also, the interface illustrated in a solid line denotes the transmission of data of the user plane.
FIG. 6 shows a network overload state.
As illustrated in FIG. 6, if traffic is overloaded or congested at an interface between the (e)NodeB 20 and the S-GW 52, or traffic is overloaded or congested at an interface between the Home (e)NodeB 30 and the S-GW 52, then downlink data to the UE 10 or upload data from the UE 10 is failed to be properly transmitted.
Also, if an interface between the S-GW 52 and the PDN-GW 53 or an interface between the PDN-GW 53 and an Internet Protocol (IP) service network of the mobile communication operator is overloaded or congested, then downlink data to the UE 10 or upload data from the UE 10 is failed to be properly transmitted.
Also, when UE is handed over from a cell being currently serviced to another cell, if the another cell is overloaded, then it will cause a problem of dropping the service of the UE.
In order to solve the foregoing problem, mobile communication operators have changed the S-GW 52 and the PDN-GW 53 to high-capacity devices or have installed more new devices, but it has a disadvantage of requiring very high cost. Furthermore, it has a disadvantage that the amount of transmitted or received data increases exponentially over time, and then overloaded in a short time.
On the other hand, various schemes for optimizing the S-GW 52 and the PDN-GW 53 without installing more mobile communication networks as described above have been presented. For example, there has been presented a technology of making a selected IP traffic offload, namely, SIPTO, in which an optimal path is selected to transmit specific IP traffic (for instance, Internet service) of the UE in a macro access network, and the IP traffic is offloaded to a path through nodes of a public network that is not the mobile communication network, i.e., nodes of a wired network, in a Femto access network (e.g., Home (e)NB), without transmitting or receiving the IP traffic via a path over the mobile communication network.
FIG. 7 shows the concept of Selected IP Traffic Offload (SIPTO).
Referring to FIG. 7, a mobile communication system such an Evolved Packet System (EPS) is illustrated in an exemplary manner. The EPC system may include (e)NodeB 20, MME 51, S-GW 52, and P-GW 53. Furthermore, Home (e)NodeB 30 is illustrated therein.
As illustrated in the drawing, the Selected IP Traffic Offload (SIPTO) technology may allow specific IP traffic (for instance, Internet service) of the UE 10 to be offloaded to nodes of a wired network 70 without passing through nodes within an IP service network 60 of the mobile communication operator.
For example, if the UE 10 is allowed to access the Home (e)NodeB 30, then the UE 10 can create a session passing through the wired network 70 such as a public communication network over the (e)NodeB 20 and perform an IP network service through the session. At this time, operator policy and subscription information may be considered.
This type of local gateway is called a local GGSN or local P-GW. The function of the local GGSN or local P-GW is similar to that of a GGSN or P-GW.
FIG. 8 shows the problem that the SIPTO technology is not applicable when a back-off time for preventing overload is used according to the conventional art. FIG. 9 is a procedural flowchart illustrating the situation of FIG. 8.
Referring to FIG. 8, a mobile communication system such an Evolved Packet System (EPS) is illustrated in an exemplary manner. The EPC system may include a base station 30, local P-GW 40, MME 51, S-GW 52, and P-GW 53. Furthermore, the base station 30 may be (e)NodeB or Home(e)NodeB.
The local gateway 40 is located between the base station 30 and the wired network 70, which is a gateway for enabling SIPTO through the base station 30. The local gateway 40 is allowed to create a session through a path between the base station 30 and the wired network 70.
The local gateway 40 may include part or all of the functions of PDN_GW for an EPS system, or may include part or all of the functions of gateway GPRS support node (GGSN) for UMTS. However, the local gateway 40 may be allowed to generate a bearer through a path between the base station 30 and the wired network 70, and therefore, it is differentiated from P-GW 52 of EPS or GGSN or GGSN of UMTS that generates a bearer through a path to the mobile communication network 60. Thus, it may be called a local P-GW in EPS, or may be called a local GGSN in UMTS.
On the other hand, though the system illustrated in FIG. 8 is on the basis of EPS, SIPTO illustrated in FIG. 8 may be also applied to a 3GPP Universal Mobile Telecommunication System (UMTS). In the 3GPP UMTS, both the function of the control plane in MME 51 and the function of the user plane in S-GW 52 may be carried out in a Serving GPRS Support Node (SGSN) (not shown).
The operation will be described below with reference to FIGS. 8 and 9.
If the UE 10 sends a service request, then SGSN or MME, which is a control entity within the core network, determines whether data of the service requested by the UE 10 can be offloaded to the wired network 70. That is, as can be seen with reference to FIG. 9, when the UE 10 transmits an Attach Request or TAU Request message to the base station 30, the base station 30 transmits an S1-AP interface-based Initial UE message to the MME 51, and the MME 51 transmits an Attach Accept or TAU Accept message to the UE 10. Next, the MME 51 determines whether to apply the SIPTO technology to traffic of the UE.
An access point provided through the wired network 70 such as a public network may be identical to the mobile communication network 60. Accordingly, the same Access Point Name (APN) indicating the name of an access point may be used, and SPTO permission may be designated for each APN.
In this manner, the UE 10 provides a specific APN to an entity within the core network when attempting an access, and thus an entity of the core network, for instance, MME 51 or Serving GPRS Support Node (SGSN) of EPC can determine whether or not an access of the UE 10 is offloaded to nodes of the wired network 70, such as a public network. At this time, a control entity within the core network, for instance, the MME 51, may determine whether data by the requested service is to be offloaded to the wired network 70 such as a public network by considering whether a base station accessed by the UE 10 is the (e)NodeB or Home(e)NodeB, or whether SIPTO is supported by the base station.
If it is determined that the data is offloaded, then a control entity within the core network, e.g., the MME 51, transmits a Detach Request message to the UE 10. The Detach Request message is for a re-attach procedure. As used herein, the re-attach procedure may be used to apply the SIPTO technology.
However, if the UE 10 operates the back-off timer, the UE 10 cannot perform re-attach due to the back-off time.